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Internet Key Exchange Protocol Version 2 (IKEv2) 
Abstract 
This document describes the use of the Edwards-curve Digital 
Signature Algorithm (EdDSA) in the Internet Key Exchange Protocol 
Version 2 (IKEv2). 
Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 7841. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
https://www.rfc-editor.org/info/rfc8420. 
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1. Introduction 


The Internet Key Exchange Protocol Version 2 [RFC7296] can use 
arbitrary signature algorithms as described in [RFC7427]. [RFC7427] 
defines the SIGNATURE_HASH_ALGORITHMS notification where each side of 
the IKE negotiation lists its supported hash algorithms. This 
assumes that all signature schemes involve a hashing phase followed 
by a Signature phase. This made sense because most signature 
algorithms either cannot sign messages bigger than their key or 
truncate messages bigger than their key. 


EdDSA [RFC8032] defines signature methods that do not require 
prehashing of the message. Unlike other methods, these accept 
messages of arbitrary size, so no prehashing is required. These 
methods are called Ed25519 and Ed448; they use the Edwards 25519 and 
the Edwards 448 ("Goldilocks") curves, respectively. Although that 
document also defines prehashed versions of these algorithms, those 
versions are not recommended for protocols where there is minimal 
burden in buffering the entire message so as to make it practical to 
make two passes over the message. This is true of IKEv2. See 
Section 8.5 of [RFC8032] for that recommendation. 


EGDSA defines the binary format of the signatures that should be used 
in the "Signature Value" field of the Authentication Data Format in 
Section 3 of RFC 8032. [RFC8410] defines the object identifiers 
(OIDs) for these signature methods. For convenience, these OIDs are 
repeated in Appendix A. 


In order to signal within IKE that no hashing needs to be done, we 
define a new value in the SIGNATURE HASH ALGORITHMS notification to 
indicate that no hashing is performed. 
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Conventions Used in This Document 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in 
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 


The "Identity" Hash Identifier 


This document defines a new value called "Identity" (5) in the "IKEv2 
Hash Algorithms" registry for use in the SIGNATURE_HASH ALGORITHMS 
notification. Inserting this new value into the notification 


indicates that the receiver supports at least one signature algorithm 
that accepts messages of arbitrary size such as Ed25519 and Ed448. 


Ed25519 and Ed448 are only defined with the "Identity" hash and MUST 
NOT be sent to a receiver that has not indicated support for the 
"Tdentity" hash. 


The prehashed versions of Ed25519 and Ed448 (Ed25519ph and Ed448ph, 
respectively) MUST NOT be used in IKE. 


Security Considerations 


The new "Identity" value is needed only for signature algorithms that 
accept an input of arbitrary size. It MUST NOT be used if none of 
the supported and configured algorithms have this property. On the 
other hand, there is no good reason to prehash the inputs where the 
signature algorithm has that property. For this reason, 
implementations MUST have the "Identity" value in the 
SIGNATURE HASH ALGORITHMS notification when EdDSA is supported and 
configured. Implementations SHOULD NOT have other hash algorithms in 
the notification if all supported and configured signature algorithms 
have this property. 


IANA Considerations 
IANA has assigned the value 5 for the algorithm with the name 
"Identity" in the "IKEv2 Hash Algorithms" registry with this document 
as reference. 
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Appendix A. ASN.1 Objects 


[RFC8410] is the normative reference for the ASN.1 objects for 
Ed25519 and Ed448. They are repeated below for convenience. 


A.1. ASN.1 Object for Ed25519 


id-Ed25519 OBJECT IDENTIFIER ::= { 1.3.101.112 } 


Parameters are absent. Length is 7 bytes. 
Binary encoding: 3005 0603 2B65 70 
A.2. ASN.1 Object for Ed448 


id-Ed448 OBJECT IDENTIFIER ::= { 1.3.101.113 } 


Parameters are absent. Length is 7 bytes. 


Binary encoding: 3005 0603 2B65 71 
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